Quote from k_badam :

Unrelated to the current issue, this 'blaming the public beta testers attitude' is totally wrong. The developer is definitely responsible for any bugs or issues in the game, if the community fail to find them it is still the fault of the development team.

To be clear, there isn't a bug or an issue, so I'm not blaming anyone for it.


EDIT: I am saying, that people who have a special minority interest, should definitely have a go with the test patch which was there for weeks. There were many repeated requests for testing, warnings of the changes and so on. So there is no sense in complaining if after all those requests, someone with a minority interest refuses to test the patch then when it is released, it turns out that one small beneficial change isn't to their liking. There's nothing more I can do, than put all these test patches out for public testing, ask people to test them and fix any issues they report. So don't ask me to do more than that.

This is why I'm suggesting, get outside for a little each day. A lot of people have discovered the great outdoors during lockdown, but still more people have not understood that you can go outside, or believed that it is beneficial in any way. But it is very important to get outside every day. Or at least nearly every day, probably not if there's a storm out there.

Last edited by Scawen, Tue 2 Mar 2021, 09:25.

It's your mistake. This is the beauty of public test patches.

Learn and move on.

Also: It's actually a good thing that there is some new opportunity for some hotlap activity. So your failure to bother to test your own special interest has resulted in some good fun for a few people. So that's good!

Seems you don't seem to have much idea how things work around here.

You can only really be upset with yourself for not spotting this during the test patch phase.

Better get over it and go and have some fun racing and hotlapping.

Quote from Viperakecske :

KY1 OVAL FBM is now -0:00.030 faster than old r3 wr.
I dont see the point releasing new hard tyre

But do you see the point of long periods of test patch availability?

I'm not sure what you mean. Are you talking about some shimmering of thin objects and also other things that appear 'thin' such as dark lines on the track in the distance?

There's not much to be done about that in this version and I don't think you are talking about a new issue in the test patch. But you might get slightly better results with 8x AA.

Thank you all for the feedback and testing.

Test Patch U25 is now available. I hope it's the last test patch.

Please have a go with it if you can.

Changes from 0.6U24 to 0.6U25: COMPATIBLE WITH U23 AND U24

Training:

FIX: AI changed to low fuel load if overtaking lesson restarted
FIX: AI skill / admin commands no longer processed during training
FIX: Training lesson did not end if replay saving was interrupted
FIX: Refuelling depended on refuelling allowed in single player
FIX: Logo was visible under title during lesson replay

OutSim:

OutSim packet is documented in docs\OutSimPack.txt
Added steering torque as additional field in new OutSim
All data options can be switched on with OutSim Opts 1ff

Misc:

Removed debug message "Replay name : temp_mpr"
Saving replay name now shown beside option in Options - Game

https://www.lfs.net/forum/thread/95016

Quote from thegamer147 :

Are we getting the final patch soon? I can't wait to test it

Please test now. There is little point testing after the official version is released!

Quote from MacedoSTI :

you know what i said is not off topic

Yes, you instructed me to update the driver models, but that is off topic.

I fixed the driver animations to deal with new steering limits. It's not closely related to working on the driver models.

Last edited by Scawen, Sat 27 Feb 2021, 00:01.

Quote from Degats :

One observation, the IS_RES TTime ("session time") doesn't quite match the IS_LAP ETime ("total time")
...
If I understand correctly, the IS_RES time is equivalent to the replay time and IS_LAP is equivalent to the time since the lights go green?

I've noticed that some packets have ETime and others are TTime - are they always consistent with the interpretation of the two times above?

Thanks for the test.

Yes, the IS_RES TTime in practice mode is the time since the start of the session until... and here is the dirty secret... the time the packet is processed at the server (a short and unpredictable time after the packet is sent - in this case 0.47 seconds). And, as you said, the IS_LAP ETime is the time since the lights go green (3 seconds after the start of the session) until the time the car crossed the finish line. So that's how to get the 3.47 seconds difference.

Explanation: The IS_LAP is triggered by an internal packet that has a proper time stamp (from the driver's computer) of total time as that is very important for accuracy. But the internal result packet that triggers the IS_RES packet in qualifying mode doesn't have that accurate time stamp as it was never needed before. So the server goes with the time the packet is processed for this new use of TTime in IS_RES in qualifying. I think for the purposes you are describing, that additional slight delay won't be a problem. I think it could only be a problem if two qualifiers cross the finish line at almost exactly the same time, with exactly the same lap time, then the tie-break between these two identical laps might not get the right order. But that might never happen! And if it did happen I think that would match the order generated by LFS...

EDIT: Sorry, this isn't quite right as they are both triggered by the same internal packet. So I think it would be possible to make the IS_RES TTime in qualifying equal to the associated IS_LAP ETime if needed, by passing some extra parameters to a couple of functions. But then the order might not match the order generated by LFS in that very rare case described.

Quote from vanopaniashvili :

Increasing the range of steering wheel rotation is welcome news and I got a question about it. What was the reason behind changing all street cars to 900 degrees of rotation?

I'm concerned about the non-wheel users of LFS. It's certainly gonna affect their understanding of vehicle handling characteristics which they are already familiar with and force them to rethink everything. Obviously, steering ratios play a huge role in letting you know about the handling character of a vehicle and LFS was always familiar with 720 degrees of rotation, which gave a certain steering ratio output while being paired with default 36 degrees of steering lock. It gave street cars a certain driving characteristic, which is also what most of the users are familiar with. Changing LFS's signature steering ratio, might cause a confusion in LFS users.

I always knew the steering wheel turns in LFS were too low, compared with real road cars. I had already changed most of the road cars in the development version to the new value. It is an old request to update the steering angles, maybe ever since the higher range controller wheels were available. So now as I was dealing with wheel turns on the racing cars I started to look into steering ratios.

Side note for anyone who doesn't know: steering ratio is the degrees turned by the steering wheel, compared with the degrees turned by the front wheels. https://en.wikipedia.org/wiki/Steering_ratio

Normally in road cars this is between around 12:1 and 18:1 - usually closer to around 15:1 - but in LFS previous versions:
- FWD road cars had a ratio of 12:1 (720 deg steering wheel for 60 deg road wheel)
- RWD road cars had a ratio of 10:1 (720 deg steering wheel for 72 deg road wheel)

So the previous version of LFS was outside of the values ever seen in real road cars. With the new adjustment, the FWD cars have a ratio of 900:60 which is 15:1 and the RWD have a ratio of 900:72 which is 12.5:1 and this is closer to reality (though still a bit low in the RWD case).

I know this will make the cars feel different, while having the same underlying physics, but I'm hoping that as it's closer to reality that shouldn't be a bad thing.

EDIT: This change should not affect mouse or keyboard users at all. In their case the keyboard or mouse operates the steering directly so there is only a graphical change. The change in feeling should only affect wheel users and maybe has a slight affect on joystick users.

Quote from tankslacno :

Hi! I've noticed several strange things and bugs in training lessons. At least one of them is related directly to this test patch and I found two others due to me trying to test that new Live Replay-feature in this test patch, meaning that they could be related to this test patch as well.

Thanks for the detailed descriptions.

Some of them I won't worry about but I will have a look to see if some of them can be corrected easily.

Last edited by Scawen, Fri 26 Feb 2021, 10:33.

Quote from Degats :

Would it be possible to set TTime to the session time when the lap was completed, or is there a technical reason why it can't be?

You should find the TTime in IS_RES now has the qualifying session time. Please let me know if it looks right. I did a quick test with the IS_RES appearing live and when requested with TINY_RES.

Test Patch U24 is now available with updated steering animations and new steering wheel rotation limits. Road cars now have 900 degrees steering wheel turn instead of 720. XF and UF GTR now have 540 degrees instead of 720. The new values are more realistic. This may affect the feeling of the cars if you use a wheel.

Steering:

Road cars now have 900 degrees steering range with default setup
XF and UF GTR have 540 degrees steering range with default setup
Updated and fixed steering animations to cover new steering range
Removed option "Move view with animation" which had little effect
FIX for new bug: Steering wheel could turn too far with some setups
FIX for new bug: Switching setups while driver visible could crash

InSim:

IS_RES: TTime in qualifying now indicates time in session
IS_RES: PLID is now zero if the player has left the race

Misc:

Blocked messages remain blocked when returning from game to lobby
Command /block [0/1/2] : block user messages (like the minus key)

Translations:

More updated translations. Thank you very much, translators.

https://www.lfs.net/forum/thread/95016

Quote from Gutholz :

It is not possible to assign "block chat" to a button. It is hardcoded to the minus-key "-" and that key is not supported by the /press function.

In the current test patch, you can use the command /press minus (or /shift minus)

In the version I should release this afternoon, there is also a new text command /block X
/block [0/1/2] - block messages (none / user / all)

OK, the test patch won't be today. I've updated all the steering animations and set all the road cars to have 900 degrees of steering wheel rotation with the default steering lock. There are a few more things to do, so hopefully a test patch tomorrow.

Quote from martin18 :

Scawen is there anything we can do about steering lock and steering degrees? When set to 45 degrees max steer lock steering turns now to 900. Now when set to anything past that the vehicle steering wheel can not be matched to racing wheel.

Yes, I have noticed that bug. If you increase the maximum lock, at the point you reach "Car's steering wheel turns 1080 degrees" then everything is OK. The bug comes when you continue to increase the steering lock past that point, the screen display still says 1080 degrees but the in-game wheel turns further. I've fixed that in my version and I'm also updating the steering animations to keep going up to the new limits.

I plan to release another patch that is compatible with the current test patch, hopefully on Wednesday. Nothing very exciting in it but a few fixes.

It is CPU, not GPU, time which is being measured. Actually it's just time itself between one point and another.

The "Draw" section is supposed to represent the time taken for the CPU to work out everything related to drawing the shadows, environment maps, mirrors, main views, etc. During this time there are a lot of calculations and thousands of calls to D3D to set constants, set active textures, set vertex and index buffers, and request sections of those buffers to be drawn. Even some vertices and triangles to be sent to the GPU every frame (for flexible objects like drivers and tyres). There is a *lot* of work for the CPU to do when drawing.

That is why it can help to separate physics and rendering onto separate threads. The GPU doesn't just magically know what do to, it is instructed by thousands of calls every frame, from the CPU, through Direct3D. If the CPU didn't have to do much then there would be no need for a separate thread for rendering.

However, there is something seemingly anomalous about a high value in "Draw" in certain situations. In my case I can make Draw go over 90% by selecting exclusive mode full screen (SHIFT+F10) with Vertical Sync enabled. I don't know exactly why that is without looking into it, but it seems quite certain that the time while we are waiting for the vertical sync, is within the start and end of the section I have marked as "Draw". It's nothing to worry about.

If I go full screen in borderless window mode (SHIFT+F11) then the waiting time is in "Flip" which I would have expected to be the case in exclusive mode full screen too. So that's the only anomaly but I'm not really too worried about it.

Without vertical sync enabled, but frame rate limited, the spare time moves into "Sleep" so we get a much better reading for how long the Draw is taking. If you disable frame rate limitation then frame rate goes insane and Draw goes up to a high number. That is expected as we are asking LFS to draw as many frames as possible with every scrap of time remaining.

That is only a waste of energy. Frame rate should either be limited to a set value or vertical sync should be used. There is no point in extremely high frame rates, specially since the new test patches have sorted out a controller issue that previously caused high frame rates to be useful for force feedback.

I repeat - that is no longer the case. Please save some energy and heat by limiting frame rate (e.g. 100 fps) or using vertical sync if you prefer.

Last edited by Scawen, Thu 18 Feb 2021, 10:03.

All the vehicles with front wheel drive (including four wheel drive) have less steering lock because of the CV joint in the front drive system. Of course in LFS the CV joint doesn't really exist but we don't want to allow impossible things.

I have not researched recently into the lock limitation of CV joints. I do know that ordinary road cars with front wheel drive have a quite bad turning circle compared with RWD cars. If that was an easy problem to solve then manufacturers would do it.

Of course it would be wrong to allow extreme steering angles for vehicles with front wheel drive. There may be some cars where it is reasonable to increase the lock a bit more but I don't have any appetite for looking into that type of thing now.

As I've said a lot of times, I want to get back to the development version. It's really important to me. I hope we don't have to do any more incompatible test patches in this series. My brain already feels quite mashed with all these recent updates which were not planned. I don't regret them - I think there are so many new possibilities. But we have come to the end.

Of course, we are still in testing and I do want to know if anyone finds any issues.

Now that you can adjust your tyre width, we don't need to consider balancing the GTR class. Instead, the community and race organisers can work out what works well and specify limits for events.

Thank you for the feedback. I think it's good that we came round to a flexible system that allows so many possibilities for drifting, rallycross and hard track racing. And without messing up any existing categories or needing to reset any hotlap tables.

I'll close this thread now. Please try out the new version and leave comments on the test patch thread.
https://www.lfs.net/forum/thread/95016

Quote from Flotch :

...regarding the hotlap tables, if the new tires for some of the cars are 5mm thinner, I suppose the times done previously by the faster guys won't be reached in this new version (if that matters).

I suppose it does matter a bit. I was thinking maybe the XR GT and FZ GTR rear tyres are wider than they need to be and might even be faster with a thinner tyre due to lower wight and rolling resistance. But that might require a lot of testing that could be a waste of time.

Quote from Nadeo4441 :

What about the h-shift pattern in XRR then?

Good point, didn't think of that.

Quote from Pathseeker :

i suggest just stick with changes for those 3 GTR cars tyre change option, nothing else.

This might be the best idea, yes. But I remember race organisers use restricted UFR and XFR so maybe they would like some narrow tyres as a different type of restriction?

Quote from aanrus :

Will maybe leave it for later? When will be released the new physics, and when all the results will be deleted.

That might be the best idea, yes.

One thing I am trying to do here is escape from the trouble of balancing these new categories for racing and also for drifting. If the users can adjust tyre size then there is no problem.

If we keep the configurations then it could be that the tyre size adjustment is only applied to the new configurations. So they can be balanced for racing and drifting by users after the release. But if the code is there (and I already coded a test version of tyre width reduction) then it could easily be applied to other cars too.

Thanks for the replies, I'm just trying to think this through with you.

I am struggling to understand this. It gets to "CreateDevice" and then that's the last we see. It doesn't report that CreateDevice failed or move onto the next step. So it seems to hang in CreateDevice. But that is a Direct3D function, and your version U does it fine. Also you reported that U13 was working fine until you got a Windows update.

A couple of questions:

1) Originally you said you needed to do a hard reset. But if you start in a window, then when LFS hangs, can you use the Windows Task Manager to end the LFS process? So you don't need to restart the computer?

2) If you can start the Task Manager when LFS hangs, can you see the CPU usage of the LFS process during the hang?

In case you would like to do another test, I've collected together the LFS.exe from test patches U2 to U12 (excludes U8) into a zip file. Maybe you could try and see if any of them work. I suggest you start with U2. If it works then try U3... go through until you find the one that doesn't work. It's possible that could narrow down the changes between one version and the next that causes the problem (if it really is a problem in LFS).

http://www.lfs.net/file_lfs.php?name=LFS_EXE_6U_2_12.zip

Another Incompatible Test Patch, U22:

I hope the extra 10mm tyre width (front and rear) on the XRR make it better for drifting and a better match for the FZR in hard track racing.

Changes from 0.6U21 to 0.6U22: NEW INCOMPATIBLE VERSION

New configurations are now called ALTERNATE (not DRIFT / RX)
Small change to XR GTR alternate config - 10mm wider tyres
Virtual steering gauge hidden if live settings or pit instructions
New fuel options can be filtered and are visible on selected host
InSim IS_SPX and IS_LAP new byte Fuel200 indicates fuel remaining
FIX: Auto clutch time was wrong in the XR GTR in alternate config

https://www.lfs.net/forum/thread/95016

Quote from Degats :

Tested and working fine

Would it be an idea for the "refuelling allowed" rule to be shown on the server rules when clicking on a server in the server list? (along with pitstop required etc)

Thanks for the test and yes I should include the rules on that page.

Quote from R0ut66 :

Why change the whole system sensitivity just to make the car more driveable? For me makes no sense. LFS should have an mouse sensitivity option

As kagurazakayukari says, LFS uses the mouse movement all the way from the left side of your screen to the right side of the screen to move your car steering from the left to right extreme. So it's already as 'insensitive' as it can possibly be. Are you using full native desktop resolution for LFS? I can only think of slowing down the mouse movement in Windows (but I think you said it is already as slow as possible) and what about making sure mouse acceleration is switched off?

Quote from Extreme1234 :

How will maxing out ff steps and ff rate efect my G29? Would it make it feel more detailed? Can you explain what those values represent in ffb?

400 steps means that the steps of force go up in steps of 25 'units' where 0 is no force and 10000 is maximum force. I think the default of 400 steps and 50 Hz is enough on a G27. I don't know about a G29. To feel the effect you could reduce the number of steps to a low number then try driving a car in a slow slalom from left to right. You should notice the 'notches' as the force increases. So then you can increase the number of steps to the point where you can't feel the notches.

The reason for limiting the steps is to avoid constantly streaming new forces to the wheel, when the force hasn't changed enough to notice. This seemed to be a problem on older computers when this could reduce responsiveness by overloading the operating system with new force requests. I don't really know how much of a problem it is these days to send excessive force changes. The high numbers are really for direct drive wheels where the tiniest changes become noticeable.

Thanks for the test. I hope this can solve the problem for B0mberMan.

But I would really like to know if this is a bug in the Pimax system (so Pimax developers should fix it) or if LFS is doing something wrong or could somehow detect and avoid FFR.

Quote from meuhmeuh :

So I retried and I' have a deb.log file (I don't understand):

It looks as if it started up, then 9 second later started to shut down.

Feb 03 20:26:23 init sound
[9 seconds elapsed]
Feb 03 20:26:32 shutting down

Please could you try again, using U21 test patch? There is a bit more logging.

Also if you could disable anti-virus and see if that works, that would be helpful.

Thanks!

Test Patch U21:

Interface:

Brakes / TC tab in garage separated into two columns (e.g. FZ50)
FIX: Heat in garage car's tyres was not updated when tyre changed

New handling for 'CAR.lfs' and 'shift_type.lfs' scripts:

LFS runs 'road.lfs' / 'sequential.lfs' / 'paddle.lfs' directly
(previously these scripts were called from a CAR.lfs script)
This is done after loading a car and immediately before CAR.lfs
Commands to run these scripts from another script are ignored

Graphics:

Avoid upward lighting related to ground colour in internal views

InSim:

New bytes output if /showfuel=yes
IS_NPL Fuel : initial fuel load
IS_PIT FuelAdd : fuel added

Translation update for help.txt:

host_cars - max is now 32
guest_cars - max is now 32
max_packs - max is now 12
mip_bias - default settings now -0.5 / -1.0 / -1.5 / -2.0

https://www.lfs.net/forum/thread/95016

Thank you all for the testing and feedback.

Quote from tumes925semut :

Need make that page thin.

Thanks, I'll change the Brakes / TC tab to two columns.

Quote from Flame CZE :

With the H-pattern gearbox for the RX version of XRR, the single XRR.lfs script for that car is no longer applicable for both configs. The gearbox settings have to be changed manually when switching between the configs.

I haven't checked this out yet but how about if the scripts sequential.lfs, road.lfs and paddle.lfs were run directly (not from another script) depending on the actual shift type after the car is loaded? And these specially named scripts would need to be excluded from being run by a /run command so they don't get run from the existing CAR.lfs scripts?

Quote from ELDemon :

Hi scawen, clutch issues on fzr also

I did a quick test with the FZR and didn't see clutch issues.
Can you describe exactly how to reproduce an issue?

Quote from THE WIZARD DK :

my test went off to a great start in garage (FXR) which inside the garage had totally flat tires. they literally sweep the floor. this was with a normal lfsw setup, normal config as i havent changed anything yet. just logged in and went into garage. and there they were simply totally flat.

I'd like to know how to reproduce this. Can you make it happen again? If so please describe exactly how, and attach the setup if this happens with a specific setup.

Last edited by Scawen, Wed 10 Feb 2021, 11:00.

Thanks. I've got your version into my test patch folder.

I've changed my version to pps 12.

The two lines you marked bold, I've changed to a single line:

More online DB access commands: https://en.lfsmanual.net/wiki/Keys